Create a mock ExecutionContext manually using a plain object cast to the interface, and pass it directly to the enhancer's method. Use Test.createTestingModule() only to resolve the enhancer with its dependencies. This approach tests the logic in complete isolation from the HTTP stack.
Guards — mock ExecutionContext and Reflector; call canActivate() directly.
Interceptors — create a mock CallHandler returning of(mockData); call intercept() and subscribe.
Pipes — call transform() directly with test values; assert return value or thrown exception.
Filters — call catch() with a mock exception and mock ArgumentsHost; assert res.status().json() calls.
Use jest.spyOn(reflector, 'getAllAndOverride') to control metadata reading in guard tests.
How would you set up a TestingModule to unit‑test a custom AuthGuard that validates a JWT token?
If a ValidationPipe throws BadRequestException on invalid input, how can you verify that behavior in an isolated test using TestingModule?
What steps do you take to mock ExecutionContext when testing an interceptor that adds a custom header?
You added an interceptor that logs request duration, but its unit test never reaches the next handler. How would you adjust your TestingModule to isolate the interceptor and simulate the handler?
During a refactor a guard that depends on ConfigService started returning undefined in tests. Walk me through debugging the TestingModule configuration to fix it.
Why does your pipe test pass with a real DTO but fail with a mocked object, and how would you restructure the test?
When building a library of reusable guards, interceptors, and pipes, how would you design a shared TestingModule strategy that minimizes duplication while keeping tests fast and reliable?
At scale you notice unit tests for many interceptors are flaky due to shared global providers. What architectural changes would you make to the testing setup to isolate each component?
Discuss the performance implications of using Nest's Test.createTestingModule versus manually instantiating the class for guard testing, and when you'd choose one over the other.
Your organization is migrating from a monolithic NestJS app to microservices. How would you evolve the testing approach for guards, interceptors, and pipes to ensure consistency across services while avoiding duplicated test code?
Across multiple teams there are differing conventions for testing Nest components. Propose a company‑wide guideline for testing guards/interceptors/pipes in isolation, covering tooling, CI integration, and long‑term maintenance.